MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 138

Text File | 1996-03-23 | 52KB | 1,428 lines

C.S.M.P. Digest             Wed, 28 Feb 96       Volume 3 : Issue 138

Today's Topics:

        Can't sync up to VBL...
        Confused about MDEF!
        CopyBits, SetGWorld, and Everything (tm)
        Drag & Drop and Trash
        Drag Manager: How to have custom clippings
        Idle time
        KanjiTalk ignores GNEFilters?
        [ANN] GC 4.9 for MacOS
        [ANN] Visit Mac Games Programmers' Bitstop!



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From Mikael <[e-mail]>
Subject: Can't sync up to VBL...
Date: 10 Feb 1996 23:57:11 GMT
Organization: Association Resus

Hi all.

  Here is my problem:
 I've been trying to sync up my code to the VBL of the screen and so far, I've
succeeded only on one of my friend's 630. But on my 7200, it just won't work...
 What I'm doing is to use SlotVInstall after finding out the slot number of my
screen, and giving it a pointer to my procedure, the one that is to be called
for each of the screen's VBL. It'works just fine on the 630, but it seems that
I'm missing something about the way you give a ProcPtr to the system on a
Powermac... (note that it doesn't even work when trying to do that with the
vanilla 60 Hz VBL queue). All I have as a documentation is a 1992 version of
Think Reference, and it doesn't explain what changed in the system with the
Powermac (obviously... the powermac didn't exist at that time...). I've been
peeking in CodeWarrior's header files to try to figure it out, but I don't know
anything about the different flavors of UPP's, and I just can't get the system
to call my procs without crashing.

 Think Reference also explains how you should save and restore the A5 register
to allow your proc to acces your application's global variables, but I don't
know how you fit that to the powermac...

 And last thing, I've also been trying to play real-time generated sound using
SndPlayDoubleBuffer. But here again, I can't pass the informations about my
callback procedure to the system in a working way (here, the first buffer plays
well and then the whole thing crashes when the system tries to call my proc).


 I hope someone can help me on these ones because I think I won't figure them
out on my own...

 Thanks in advance.

       Mikael Bouillot ([e-mail])


+++++++++++++++++++++++++++

>From John Burch
Date: 11 Feb 1996 22:31:29 GMT
Organization: ProAccess Systems Inc.

In article <4fjbcn$[e-mail]>, [e-mail] says...
>
>Hi all.
>
>  Here is my problem:
> I've been trying to sync up my code to the VBL of the screen and so far, I've
>succeeded only on one of my friend's 630. But on my 7200, it just won't work...
> What I'm doing is to use SlotVInstall after finding out the slot number of my
>screen, and giving it a pointer to my procedure, the one that is to be called
>for each of the screen's VBL. It'works just fine on the 630, but it seems that
>I'm missing something about the way you give a ProcPtr to the system on a
>Powermac... (note that it doesn't even work when trying to do that with the
>vanilla 60 Hz VBL queue). All I have as a documentation is a 1992 version of
>Think Reference, and it doesn't explain what changed in the system with the
>Powermac (obviously... the powermac didn't exist at that time...). I've been
>peeking in CodeWarrior's header files to try to figure it out, but I don't know
>anything about the different flavors of UPP's, and I just can't get the system
>to call my procs without crashing.
>
> Think Reference also explains how you should save and restore the A5 register
>to allow your proc to acces your application's global variables, but I don't
>know how you fit that to the powermac...
>
> And last thing, I've also been trying to play real-time generated sound using
>SndPlayDoubleBuffer. But here again, I can't pass the informations about my
>callback procedure to the system in a working way (here, the first buffer plays
>well and then the whole thing crashes when the system tries to call my proc).
>
>
> I hope someone can help me on these ones because I think I won't figure them
>out on my own...
>
> Thanks in advance.
>
>       Mikael Bouillot ([e-mail])
>


Mikael,
This code works fine on a 7100 PPC - it's standard code from Apple I think.
Maybe there's a problem with the code that
is called by the VBL. Hope it helps.


OSErr InstallVBL ()
{
long    anErr;
Str255    Temp;
short    MainSlotNumber,  mainDeviceRefNum;


    gMyVBLRec.myVBLTask.qType = vType;
    gMyVBLRec.myVBLTask.vblAddr = (ProcPtr) DoVBL;// address of task
    gMyVBLRec.myVBLTask.vblCount = kInterval; // Set the interval
    gMyVBLRec.vblA5 = (long) CurrentA5; // Save app's A5 in structure

    mainDeviceRefNum = (**GetMainDevice()).gdRefNum;
    MainSlotNumber = (**(AuxDCEHandle)GetDCtlEntry(mainDeviceRefNum)).dCtlSlot;

    anErr = SlotVInstall ((QElemPtr) &gMyVBLRec.myVBLTask, MainSlotNumber);

    return anErr;
}

void DoVBL()
{
    long    curA5;
    VBLRecPtr    recPtr;

    recPtr = (VBLRecPtr) GetVBLRec ();
    curA5 = SetA5 (recPtr->vblA5);// read app A5 from structure and save
            // current value of A5
    // ...  now that it's OK to access application variables, do the task ...

    fastDraw(recPtr);

     // Reset vblCount so that this procedure executes again
    recPtr->myVBLTask.vblCount = kInterval;
    curA5 = SetA5(curA5);
}


John


+++++++++++++++++++++++++++

>From [e-mail] (Henry van Tunen)
Date: 12 Feb 1996 06:15:23 GMT
Organization: Motionworks Group Limited

In article <4fjbcn$[e-mail]>, Mikael
<[e-mail]> wrote:

> Hi all.
>
>   Here is my problem:
>  I've been trying to sync up my code to the VBL of the screen and so far, I've
> succeeded only on one of my friend's 630. But on my 7200, it just won't
work...
>  What I'm doing is to use SlotVInstall after finding out the slot number of my
> screen, and giving it a pointer to my procedure, the one that is to be called
> for each of the screen's VBL. It'works just fine on the 630, but it seems that
> I'm missing something about the way you give a ProcPtr to the system on a
> Powermac... (note that it doesn't even work when trying to do that with the
> vanilla 60 Hz VBL queue). All I have as a documentation is a 1992 version of
> Think Reference, and it doesn't explain what changed in the system with the
> Powermac (obviously... the powermac didn't exist at that time...). I've been
> peeking in CodeWarrior's header files to try to figure it out, but I
don't know
> anything about the different flavors of UPP's, and I just can't get the system
> to call my procs without crashing.
>
>  Think Reference also explains how you should save and restore the A5 register
> to allow your proc to acces your application's global variables, but I don't
> know how you fit that to the powermac...
>

Hi Mikael,

I can answer the VBL stuff... The following code will set a flag that
your main program loop can test to see if it is time to draw. The flag
gets set in a VBL task (you can't do much else there since VBL's can't
move memory). This code will work for 68K, 68K CFM, and PowerPC.

typedef struct MyVBL
{
  VBLTask  vbl;
  Boolean  timeToDraw;
} MyVBL;

MyVBL gVBL;

void StartVBL( void )
{
  gVBL.vbl.qType    = vType;
  gVBL.vbl.vblAddr  = NewVBLProc( MyVBLTask );
  gVBL.vbl.vblCount = 1;
  gVBL.vbl.vblPhase = 0;
  gVBL.timeToDraw   = false;

  SlotVInstall( ( QElemPtr ) &gVBL, gTheSlot );
}

#if GENERATINGCFM
  pascal void MyVBLTask( VBLTaskPtr pVBL )
#else
  #pragma parameter MyVBLTask( __A0 )
  pascal void MyVBLTask( VBLTaskPtr pVBL )
#endif
{
   MyVBL*   pMyVBL = ( MyVBL* ) pVBL;

   pVBL.vbl.vblCount = 1;        // keep VBL alive
   pVBL.timeToDraw = true;       // it's time to draw
}

In you idle loop you can check "gVBL.timeToDraw" to see if you should
update your window. Eg:

void MyIdle( void )
{
  gVBL.timeToDraw = false;       // wait for next retrace
  while( ! gVBL.timeToDraw )
    ;
  CopyBits( ... );               // draw everything

}

Hope this helps,
--
Hank van Tunen
Senior Geek - Motion Works Group Limited.
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bretton Wade)
Date: Tue, 13 Feb 1996 11:26:44 -0500
Organization: qualia, inc.

In article <4fjbcn$[e-mail]>, Mikael
<[e-mail]> wrote:

#  Think Reference also explains how you should save and restore the A5 register
# to allow your proc to acces your application's global variables, but I don't
# know how you fit that to the powermac...

you don't need to do this on a PowerMac, also, be sure you are using the
macro to generate a callback record... it looks like this (this is
butchered out of my own code, so forgive if I missed something):

//-----------------------------------------------------------------
int         gTick = 0;
VBLTask     gVBLTask;

//-----------------------------------------------------------------
pascal   void  MyDoVBL (VBLTaskPtr rec)
{
   gTick++;
   rec->vblCount = 1;
}

//-----------------------------------------------------------------
void     InstallVBL (void)
{
   GDHandle device = GetMainDevice ();
   int   slotNum =
      (* AuxDCEHandle (GetDCtlEntry((*device)->gdRefNum)))->dCtlSlot;
   gVBLTask.qType = vType;
   gVBLTask.vblAddr = NewVBLProc (MyDoVBL);
   gVBLTask.vblCount = 1;
   gVBLTask.vblPhase = 0;
   SlotVInstall ((QElemPtr) &gVBLTask, slotNum);
}

//-----------------------------------------------------------------

--
[e-mail]
http://www.qualia.com/

---------------------------

>From Hugh Kawahara <[e-mail]>
Subject: Confused about MDEF!
Date: 11 Feb 1996 07:40:38 GMT
Organization: Stanford Univ.

Hi all! It's late Saturday evening.
Recently, I wrote a custom menu def. resource MDEF.
I intended to use it as a pop-up menu.
The program starts like
  pascal void main(short message, MenuHandle theMenu,
                               Rect *menuRect, Point hitPt, short *whichItem).
When the MDEF receives "mPopUpMsg" in the "message" parameter,
the "hitPt" parameter is supposed to contain the top-left coordinate
of the pop-up box. (This is almost a excerption from IM).
But my MDEF drew the menu at a wrong position.
I scratched my head for a while, then I swapped the hitPt.h and hitPt.v,
i.e. I used the hitPt.h as the top and hitPt.v as the left coordinate.
Surprisingly, it fixed the problem.
What did I do wrong this time?

Also, IM doesn't say anything about "mDrawItemMsg" and "mCalcItemMsg".
I was fortunate enough to find it out.
But, how can you find these "hidden" informations?

Hugh





+++++++++++++++++++++++++++

>From [e-mail] (Richard Wesley)
Date: Mon, 12 Feb 1996 10:01:32 -0800
Organization: Punch Deck Consulting

In article <4fk6hm$[e-mail]>, Hugh Kawahara
<[e-mail]> wrote:

>Hi all! It's late Saturday evening.
>Recently, I wrote a custom menu def. resource MDEF.
>I intended to use it as a pop-up menu.
>The program starts like
>  pascal void main(short message, MenuHandle theMenu,
>                                               Rect *menuRect, Point
hitPt, short *whichItem).
>When the MDEF receives "mPopUpMsg" in the "message" parameter,
>the "hitPt" parameter is supposed to contain the top-left coordinate
>of the pop-up box. (This is almost a excerption from IM).
>But my MDEF drew the menu at a wrong position.
>I scratched my head for a while, then I swapped the hitPt.h and hitPt.v,
>i.e. I used the hitPt.h as the top and hitPt.v as the left coordinate.
>Surprisingly, it fixed the problem.
>What did I do wrong this time?
>
>Also, IM doesn't say anything about "mDrawItemMsg" and "mCalcItemMsg".
>I was fortunate enough to find it out.
>But, how can you find these "hidden" informations?

This is a known bug.  I forget where its documented, but its one of those
things that they couldn't change, so we're all stuck with remembering
it...


- rmgw

http://www.punchdeck.com/hawkfish/PunchDeck.html

- --------------------------------------------------------------------------
Richard Wesley             | "I don't know about your dreams
[e-mail]     |  But mine are sort of hackneyed"
[e-mail]  |   - Laurie Anderson, "Talk Normal"
- --------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Loren Wright)
Date: Tue, 13 Feb 1996 15:35:51 GMT
Organization: Roger Wagner Publishing

> In article <4fk6hm$[e-mail]>, Hugh Kawahara
> <[e-mail]> wrote:

> >Also, IM doesn't say anything about "mDrawItemMsg" and "mCalcItemMsg".
> >I was fortunate enough to find it out.
> >But, how can you find these "hidden" informations?

I make a habit of looking at the header files.  Sometimes they have stuff
that's either missing or unclear from IM.

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 13 Feb 1996 14:10:29 -0800
Organization: Apple Computer, Inc.

In article <4fk6hm$[e-mail]>,
Hugh Kawahara <[e-mail]> wrote:

 > Also, IM doesn't say anything about "mDrawItemMsg" and "mCalcItemMsg".
 > I was fortunate enough to find it out.
 > But, how can you find these "hidden" informations?

These messages are only generated by the System 7 Popup CDEF.  If you are
handling popup menus yourself, then your MDEF need not worry about these
messages, because the Menu Manager will never generate them.

If you are using, or plan to use, the popup CDEF, then you should handle
these messages.  Unfortunately, we have never released sample code to do
this, but it shouldn't be too hard.

The MDEF gets called the same way for both messages:

The message parameter is the message.

The theMenu parameter is the MenuHandle.

The menuRect parameter is the Rect to draw in.  For mCalcItemMsg, this
will be an empty Rect and should be filled in by the MDEF.  For
mDrawItemMsg it will be the Rect to draw in.

The hitPt parameter is just the topLeft for the Rect.

The whichItem parameter is the item to display.

The only thing that looks tricky about mCalcItemMsg is that the first
thing it does is call _CalcMenuSize.  It calls _CalcMenuSize rather then
calling its internal function to do the same thing because the popup CDEF
installs a mini-MDEF that overrides to result of the mSizeMsg calculation
to adjust for the extra width of the downward pointing arrow.  If you
bypass that then the menu won't be sized correctly.

mDrawItemMsg simply calls through to the same code that draws individual
items for the menu itself.

- ---------

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From [e-mail] (Chad Leigh @ The Electronic GunShop)
Subject: CopyBits, SetGWorld, and Everything (tm)
Date: Tue, 06 Feb 1996 03:05:42 -0700
Organization: Pengar Enterprises, Inc.


Hi All

I have a quick question:

I whipped up a quick program over the weekend and ran into some questions.

My program has 3 offscreen GWorlds and a Window for final display.  I
develoepd it on a PPC using MW CW 8.0 (straight C).  I compiled both PPC
and 68K versions and both ran fine on the PPC (7.5.2).

I moved the 68K version to my brothers IIsi (7.1) and it didn't work right
in some places.

The program uses CopyBits from the GWorlds to other Gworlds and to the
Window on-screen.

That is the background.

Now the questions:

1.  Is it necessary to do a SetGWorld to the *destination*
Gworld/CGrafport before doing the CopyBits?     NIM:ImagQDraw (IQD) seems
to imply that you need to do this. (at least for the window).  Looking at
the examples in NIM:IQD they do this.  But after having troubles on the
IIsi, and then looking at example code, like in the "Tricks of the Mac
Game Programming Gurus", they do lots of CopyBits without ever Setting any
port (equivalent) that I could tell.  Looking at various example in
different places, some do it and some don't.

After setting the gworld (SetGWorld) my code now works on the IIsi (it
always worked on the PPC).  (I do some simple animations as pieces move on
a field and the piece on the PPC would move nicely in a slide to its next
position -- on the IIsi it would hesitate for a second and then jump to
its new position. (The hesitation was the "sliding" loop but it didn't
show up on the screen.  Now it all works on both machines).


2.  LockPixels() -- NIM says that you need to do this before doing a
CopyBits into or from a GWorld (NIM:IQD 6-9 -- 4th paragraph down).  Lots
of examples don't.  I always have but after seeing others not I am
wondering?

Is setting the NoPurge (default) flag in the NewGWorld call enough to not
have to do this?  I ask because NIM:IQD does NOT make this qualification
and also because maybe there is a technical difference between "purging
(out of memory)" and merely "moving" the base address.

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Tue,  6 Feb 1996 12:02:56 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Chad Leigh @ The Electronic GunShop) writes:
> I whipped up a quick program over the weekend and ran into some questions.
>
> My program has 3 offscreen GWorlds and a Window for final display.  I
> develoepd it on a PPC using MW CW 8.0 (straight C).  I compiled both PPC
> and 68K versions and both ran fine on the PPC (7.5.2).
>
> I moved the 68K version to my brothers IIsi (7.1) and it didn't work right
> in some places.
>
> The program uses CopyBits from the GWorlds to other Gworlds and to the
> Window on-screen.
>
> That is the background.
>
> Now the questions:
>
> 1.  Is it necessary to do a SetGWorld to the *destination*
> Gworld/CGrafport before doing the CopyBits?     NIM:ImagQDraw (IQD) seems
> to imply that you need to do this. (at least for the window).  Looking at
> the examples in NIM:IQD they do this.  But after having troubles on the
> IIsi, and then looking at example code, like in the "Tricks of the Mac
> Game Programming Gurus", they do lots of CopyBits without ever Setting any
> port (equivalent) that I could tell.  Looking at various example in
> different places, some do it and some don't.

Yes, it is necessary. If the destination of the CopyBits has a
graphics device which is different from the one which is currently set
by SetGWorld(), you can get color or speed problems.

> 2.  LockPixels() -- NIM says that you need to do this before doing a
> CopyBits into or from a GWorld (NIM:IQD 6-9 -- 4th paragraph down).  Lots
> of examples don't.  I always have but after seeing others not I am
> wondering?

It's like locking any other handle. Maybe you can get away with not
locking it before you use it. Then one day you (or your user) finds a
sequence of actions which causes a memory allocation, and suddenly
you're writing to an invalid pointer. Crash bang.

> Is setting the NoPurge (default) flag in the NewGWorld call enough to not
> have to do this?  I ask because NIM:IQD does NOT make this qualification
> and also because maybe there is a technical difference between "purging
> (out of memory)" and merely "moving" the base address.

No. There *is* a difference between purging a handle and leaving it
unlocked. You pretty much stated it: if it's got the nopurge flag, it
will never actually be deleted, but it still may be moved, unless you
LockPixels() it.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Bill Catambay)
Date: Tue, 06 Feb 1996 09:28:59 -0800
Organization: Marathon Map Makers Guild

In article <[e-mail]>, [e-mail]
(Chad Leigh @ The Electronic GunShop) wrote:

> Hi All
>
> I have a quick question:
>
>
> 1.  Is it necessary to do a SetGWorld to the *destination*
> Gworld/CGrafport before doing the CopyBits?

Yes, you need to SetGWorld to destination GWorld, and/or SetPort to
destination GrafPort.

>
>
> 2.  LockPixels() -- NIM says that you need to do this before doing a
> CopyBits into or from a GWorld (NIM:IQD 6-9 -- 4th paragraph down).  Lots
> of examples don't.  I always have but after seeing others not I am
> wondering?
>

With GWorlds, yes, you should lock the pixels.  You have to do this
because a GWorld actually holds its pixel map in a handle rather than a
pointer. LockPixels makes sure the pixel map doesn't move. You should lock
a GWorld's pixels before drawing to or copying from the GWorld (and unlock
them afterward).

_____________________________________________________________________
Bill Catambay
Pascal Programmer on Macintosh and Open VMS

              />
             //   The purpose of software engineering
     (//////[O]>=========================================-
             \\    is to manage complexity, not to create it.
              \>

____________________________________________________________________
Marathon lovers: Check out Devil in a Blue Dress, a 20-level custom map scenario with new story and plots.

+++++++++++++++++++++++++++

>From [e-mail] (Chris De Salvo)
Date: Tue, 06 Feb 1996 21:44:38 -0800
Organization: MacPlay

In article <[e-mail]>, [e-mail]
(Chad Leigh @ The Electronic GunShop) wrote:

>1.  Is it necessary to do a SetGWorld to the *destination*
>Gworld/CGrafport before doing the CopyBits?     NIM:ImagQDraw (IQD) seems
>to imply that you need to do this. (at least for the window).  Looking at
>the examples in NIM:IQD they do this.  But after having troubles on the
>IIsi, and then looking at example code, like in the "Tricks of the Mac
>Game Programming Gurus", they do lots of CopyBits without ever Setting any
>port (equivalent) that I could tell.  Looking at various example in
>different places, some do it and some don't.

   CopyBits() uses the current grafport (in this case a GWorld) to
determine clipping and other such info when transfering bits.  As such,
you should do a SetGWorld() to the destination before blitting.

>2.  LockPixels() -- NIM says that you need to do this before doing a
>CopyBits into or from a GWorld (NIM:IQD 6-9 -- 4th paragraph down).  Lots
>of examples don't.  I always have but after seeing others not I am
>wondering?
>
>Is setting the NoPurge (default) flag in the NewGWorld call enough to not
>have to do this?  I ask because NIM:IQD does NOT make this qualification
>and also because maybe there is a technical difference between "purging
>(out of memory)" and merely "moving" the base address.

   My feeling on this is that since the pixels are held in a handle-based
data structure, they could be relocated in RAM during a Memory Manager
operation.  CopyBits() could cause memory to be moved.  Who knows when
this could happen.  The NoPurge flag will keep them from being cleared
from RAM, but won't stop them from moving.  It would be bad for the bits
to move in the middle of a blit.  I would recommend having your pixels
locked.

If those three GWorlds aren't being resized or anything during the life of
your program, just lock them right after you allocate them, and unlock
before you free them.  That way you don't have to worry about them.
Assuming that you do this early on in your program, they should be in a
friendly place in the heap.

L8R
Chris

--
[e-mail]         |   Macintosh:  Changing the world,
Chris De Salvo              |        one person at a time!
Professional Mac Geek       |    -----------------------------
for MacPlay, Inc.           |      (I wish they'd hurry up!)

           http://www.deltanet.com/users/phixus

+++++++++++++++++++++++++++

>From [e-mail] (Kenneth Worley)
Date: Wed, 14 Feb 1996 09:12:21 -0700
Organization: The Computer Den, Inc. Evanston WY

In article <[e-mail]>, [e-mail]
(Chad Leigh @ The Electronic GunShop) wrote:

> 1.  Is it necessary to do a SetGWorld to the *destination*
> Gworld/CGrafport before doing the CopyBits?     NIM:ImagQDraw (IQD) seems
> to imply that you need to do this. (at least for the window).  Looking at
> the examples in NIM:IQD they do this.  But after having troubles on the
> IIsi, and then looking at example code, like in the "Tricks of the Mac
> Game Programming Gurus", they do lots of CopyBits without ever Setting any
> port (equivalent) that I could tell.  Looking at various example in
> different places, some do it and some don't.
>
> After setting the gworld (SetGWorld) my code now works on the IIsi (it
> always worked on the PPC).  (I do some simple animations as pieces move on
> a field and the piece on the PPC would move nicely in a slide to its next
> position -- on the IIsi it would hesitate for a second and then jump to
> its new position. (The hesitation was the "sliding" loop but it didn't
> show up on the screen.  Now it all works on both machines).

Looks like you answered your own question. I always understood that you do,
in fact, have to set the destination port before doing a CopyBits. In fact,
the destination port's fore and background colors affect the CopyBits
operation.

> 2.  LockPixels() -- NIM says that you need to do this before doing a
> CopyBits into or from a GWorld (NIM:IQD 6-9 -- 4th paragraph down).  Lots
> of examples don't.  I always have but after seeing others not I am
> wondering?
>
> Is setting the NoPurge (default) flag in the NewGWorld call enough to not
> have to do this?  I ask because NIM:IQD does NOT make this qualification
> and also because maybe there is a technical difference between "purging
> (out of memory)" and merely "moving" the base address.

NoPurge just keeps the relocatable block from being let go. It doesn't do
anything to actually lock the BitMap in place. Even though CopyBits will
work a lot of times when you don't lock the pixels, there are always a
few circumstances where it won't. I always understood though that you only
need to lock the pixels of the GWorld you're copying FROM. Anyone else know
if that's correct or not?

- ---------------------------------------------------
  Kenneth Worley
  [e-mail]
- ---------------------------------------------------

---------------------------

>From [e-mail] (Hiroshi Lockheimer)
Subject: Drag & Drop and Trash
Date: Sun, 04 Feb 1996 05:18:34 +0900
Organization: Twics Co. Ltd., Japan

Hi all:

I'm wondering if there's any code on how to determine if something has
been dragged into the trash.

Basically, I want the user to be able to drag some list items (as in the
List Manager) around, and if the user wants to delete the item, dropping
it into the trash would do the job (Anarchie and Netscape both do this).

So far I have it working by installing a custom DragSendProc and
determining inside this proc (via GetDropLocation, etc.) if the user
dragged into the trash and if so, deleting the current selection from my
list.  HOWEVER, I can't for the life of me figure out how to get the Drag
Manager _not_ to do the "zoom" effect back from the trash to where the
deleted item used to be.

Do I have to write a custom drawing proc to bypass the "zoom"?  Any hints?

TIA,
Hiroshi Lockheimer

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 7 Feb 1996 16:51:11 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Hiroshi
Lockheimer, [e-mail] writes:

>I'm wondering if there's any code on how to determine if something has
>been dragged into the trash.

Here's a bit of code that I use:

Boolean drop_pos_is_trash (DragReference drag_ref)
{
  Boolean   result = false;
  Boolean   changed;
  AEDesc    drop_location;
  AliasHandle  drop_alias;
  FSSpec    drop_file_spec;
  FSSpec    trash_file_spec;
  short     trash_vRefNum;
  long      trash_dirID;

  if ( GetDropLocation(drag_ref, &drop_location) == noErr )
    {
      drop_alias = (AliasHandle)drop_location.dataHandle;
      if (
         drop_location.descriptorType == typeAlias &&
         ResolveAlias( nil,
                       drop_alias,
                       &drop_file_spec,
                       &changed) == noErr &&
         FindFolder( kOnSystemDisk,
                     kTrashFolderType,
                     kDontCreateFolder,
                     &trash_vRefNum,
                     &trash_dirID) == noErr &&
         FSMakeFSSpec( trash_vRefNum,
                      trash_dirID,
                      nil,
                      &trash_file_spec) == noErr &&
         equal_file_specs(&trash_file_spec, &drop_file_spec)
         )
             result = true;
      AEDisposeDesc(&drop_location);
    }
  return(result);
}

Boolean equal_file_specs (FSSpec *file1, FSSpec *file2)
{
  return
    IUEqualString(file1->name, file2->name) == 0 &&
    file1->vRefNum == file2->vRefNum &&
    file1->parID == file2->parID;
}

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Sat, 10 Feb 1996 12:57:47 -0800
Organization: Cellular

In article <[e-mail]>,
[e-mail] (Hiroshi Lockheimer) wrote:

 > I'm wondering if there's any code on how to determine if something has
 > been dragged into the trash.
 > So far I have it working by installing a custom DragSendProc and
 > determining inside this proc (via GetDropLocation, etc.) if the user
 > dragged into the trash and if so, deleting the current selection from my
 > list.  HOWEVER, I can't for the life of me figure out how to get the Drag
 > Manager _not_ to do the "zoom" effect back from the trash to where the
 > deleted item used to be.

Add data to your drag item of type 'promiseHFS'. (I don't have headers
lying around at the moment, so you'll have to search in <Drag.h> for that
sub-string to get the real constant.) Implement the whole ritual for that
data flavor as documented in Drag Manager Programmer's Guide. You may or
may not actually have to create a file in the trash to satisfy Finder and
Drag Manager that you've done the right thing. If you do have to create
the file, simply delete it right after TrackDrag returns. (Its FSSpec will
still be in the drag reference.)

NewsWatcher may or may not do it this way, but it's easy to check.

- -----------------------------

  Pete Gontier -- Apple Macintosh Developer Technical Support
  <URL:mailto:[e-mail]> -- <URL:http://www.dnai.com/~gurgle>

+++++++++++++++++++++++++++

>From [e-mail] (Ari Halberstadt)
Date: Sun, 11 Feb 1996 23:52:10 -0400
Organization: Shore.Net/Eco Software, Inc; ([e-mail])

In article <[e-mail]>, [e-mail]
(Pete Gontier) wrote:

>In article <[e-mail]>,
>[e-mail] (Hiroshi Lockheimer) wrote:
>
> > I'm wondering if there's any code on how to determine if something has
> > been dragged into the trash.
> > So far I have it working by installing a custom DragSendProc and
> > determining inside this proc (via GetDropLocation, etc.) if the user
> > dragged into the trash and if so, deleting the current selection from my
> > list.  HOWEVER, I can't for the life of me figure out how to get the Drag
> > Manager _not_ to do the "zoom" effect back from the trash to where the
> > deleted item used to be.
>

There's another way to detect a drag to trash. This is hacked out of some
C code. I'm not sure about how to disable the zoom effect.

...
      /* track the drag */
      err = TrackDrag(drag, &event, dragRgn);
      if (err != dragNotAcceptedErr && err != userCanceledErr) {
         ThrowIfOSError(err);

         /* delete the selection if it was dropped onto a
            destination to which the selection should be
            moved instead of copied (i.e., to the trash) */
         ThrowIfOSError(GetDragModifiers(drag, 0L, &mouseDownModifiers,
&mouseUpModifiers));
         if (  (mouseDownModifiers & optionKey) == 0 &&
               (mouseUpModifiers & optionKey) == 0 &&
               DragTargetIsTrash(drag))
         {
            // delete the selection
         }

      }
...

/* üwsDragTargetIsTrash returns true if the target of the drag was the
   trash.

   Adapted from "DragText", by Rob Johnston, part of the Drag Manager sample
   code from Apple. */
wstBoolean wsDragTargetIsTrash(DragReference drag)
{
   AEDesc      targetDesc;
   AEDesc      targetDescSpec;
   FSSpec      targetSpec;
   CInfoPBRec  targetPB;
   short       trashVRefNum;
   long        trashDirID;
   wstBoolean  trash;

   wsTry {

      /* Coerce the target descriptor to an FSSpec. If there's no target or it
         can't be coerced into an FSSpec, then it couldn't have been the
Trash. */
      trash = false;
      wsThrowIfOSError(GetDropLocation(drag, &targetDesc));
      if (  targetDesc.descriptorType != typeNull &&
            AECoerceDesc(&targetDesc, typeFSS, &targetDescSpec) == noErr)
      {

         /* get the directory ID of the target */
         targetSpec = *(FSSpec *) *targetDescSpec.dataHandle;
         AEDisposeDesc(&targetDescSpec);
         blkclr(&targetPB, sizeof(CInfoPBRec));
         targetPB.dirInfo.ioNamePtr = targetSpec.name;
         targetPB.dirInfo.ioVRefNum = targetSpec.vRefNum;
         targetPB.dirInfo.ioDrDirID = targetSpec.parID;
         ThrowIfOSError(PBGetCatInfoSync(&targetPB));

         /* get the location of the trash folder */
         if (MacHasFindFolder()) {
            ThrowIfOSError(FindFolder(targetSpec.vRefNum,
kTrashFolderType, kCreateFolder,
               &trashVRefNum, &trashDirID));

            /* check if the target is the trash folder */
            trash = (targetPB.dirInfo.ioVRefNum == trashVRefNum &&
                     targetPB.dirInfo.ioDrDirID == trashDirID);
         }
      }

   } wsAlways {
      AEDisposeDesc(&targetDesc);
   } wsEndTry;
   return(trash);
}

-- Ari Halberstadt ([e-mail], <http://www.shore.net/~ari/>)
Computer consulting, specializing in Macintosh software development.

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 13 Feb 1996 16:42:47 -0800
Organization: Apple Computer, Inc.

In article <4fal9v$[e-mail]>,
Carl R. Osterwald <[e-mail]> wrote:

 > In article <[e-mail]> Hiroshi
 > Lockheimer, [e-mail] writes:
 >
 > >I'm wondering if there's any code on how to determine if something has
 > >been dragged into the trash.
 >
 > Here's a bit of code that I use...

The sample looked OK except that it did not appear to handle the case of
dropping into a folder which itself was in the trash. Copying to myself as
a sample code idea.

  ---

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 13 Feb 1996 18:06:45 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Hiroshi Lockheimer) wrote:

 > I'm wondering if there's any code on how to determine if something has
 > been dragged into the trash.

NewsWatcher does this (I just tested) and the source is available.

    <ftp://ftp.acns.nwu.edu//pub/newswatcher/source-212.sea.hqx>

Also:

Dev.CD Jan 96 SDK1
  Development Kits (Disc 1)
    Macintosh Drag and Drop
      Demo Applications
        FinderDrag

  ---

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From [e-mail] (Michel Pollet)
Subject: Drag Manager: How to have custom clippings
Date: Wed, 07 Feb 1996 17:00:22 +0100
Organization: SAT Euronis

I would like to have custom drag manager clippings for the finder, or, at
least, a custom icon for identifying them. for the moment, I add a PICT
representation of the object, but that's not very usefull for the end
user.

Has anybody done that ? does anybody knowns how to make custom views in
the finder like, say, CyberFinder, or Desktop printer ?

Please copy any answer by mail to [e-mail], my newsfeed is a
little erratic.

Michel

--
Michel Pollet, Macintosh developer
Email: [e-mail]                Visio (H320) : (33) 144066328

+++++++++++++++++++++++++++

>From [e-mail] (Adam Winer)
Date: Wed, 07 Feb 1996 17:04:32 -0800
Organization: Oracle Corporation

In article <michel-0702961700260001@194.98.3.103>, [e-mail]
(Michel Pollet) wrote:

> I would like to have custom drag manager clippings for the finder, or, at
> least, a custom icon for identifying them. for the moment, I add a PICT
> representation of the object, but that's not very usefull for the end
> user.
>
> Has anybody done that ? does anybody knowns how to make custom views in
> the finder like, say, CyberFinder, or Desktop printer ?

Save the clipping as an ordinary file.  To do this, you'll want to use
the "PromiseHFSFlavor" flavor type;  see the Drag Manager docs
for more info.  Also, see the GetDropLocation() function;  it'll let
you find where the file was dragged.

-- Adam Winer
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 14 Feb 1996 14:19:14 -0800
Organization: Apple Computer, Inc.

In article <michel-0702961700260001@194.98.3.103>,
[e-mail] (Michel Pollet) wrote:

 > I would like to have custom drag manager clippings for the finder, or, at
 > least, a custom icon for identifying them. for the moment, I add a PICT
 > representation of the object, but that's not very usefull for the end
 > user.
 >
 > Has anybody done that ? does anybody knowns how to make custom views in
 > the finder like, say, CyberFinder, or Desktop printer ?

It's not possible to write a clipping extension at the moment. It's a
shame, because I would certainly like to see more (jpeg, tiff, gif, rtf,
etc.).

The best you're going to be able to do, as another poster noted, is
'flavorTypePromiseHFS', which allows you to create a regular document at
the drop target. There's a good sample of how this works in the Drag and
Drop SDK:

    <ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/
        Development_Kits/Macintosh_Drag_-_Drop/
            Macintosh_Drag_and_Drop.sit.hqx

You developer programs folk can go right to the sample without downloading
the whole SDK:

Dev.CD Jan 96 SDK1
  Development Kits (Disc 1)
    Macintosh Drag and Drop
      Demo Applications
        FinderDrag

I imagine the NewsWatcher source code demonstrates this well, too.

    <ftp://ftp.acns.nwu.edu//pub/newswatcher/source-212.sea.hqx>

  ---

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From [e-mail] (Jason Hoos)
Subject: Idle time
Date: 8 Feb 1996 07:42:31 GMT
Organization: University of Illinois at Urbana

Is there some simple way to tell from within C how long a Mac has
been idle for?  If not, what's the complicated way? :)

--
     /============/       Jason Hoos - [e-mail]       \============\
    /============/   USA-CERL Graduate Database Developer    \============\
   /============/   Math Department System Co-Administrator   \============\
  /============/   University of Illinois - Urbana-Champaign   \============\

+++++++++++++++++++++++++++

>From [e-mail] (Chris De Salvo)
Date: Fri, 09 Feb 1996 04:23:01 -0800
Organization: MacPlay

In article <4fc9h7$[e-mail]>, [e-mail]
(Jason Hoos) wrote:

>Is there some simple way to tell from within C how long a Mac has
>been idle for?  If not, what's the complicated way? :)

If you define "idle" as having no mouse or keyboard activity then it's
pretty easy.  Each time through your event loop just record the mouse
position.  If it's the same as last time, the mouse hasn't moved.  Easiest
way I've found for checking keyboard activity is to use GetKeys() and then
just memcmp() each new result to the last time.

If you want to go further and check for disk/network activity, etc., then
I have no clue.

L8R
Chris

--
[e-mail]         |   Macintosh:  Changing the world,
Chris De Salvo              |        one person at a time!
Professional Mac Geek       |    -----------------------------
for MacPlay, Inc.           |      (I wish they'd hurry up!)

           http://www.deltanet.com/users/phixus

+++++++++++++++++++++++++++

>From [e-mail]
Date: Tue, 13 Feb 1996 09:30:27 GMT
Organization: Education Technology Centre of B.C.

In article <[e-mail]>,
[e-mail] (Chris De Salvo) wrote:

> In article <4fc9h7$[e-mail]>, [e-mail]
> (Jason Hoos) wrote:
>
> >Is there some simple way to tell from within C how long a Mac has
> >been idle for?  If not, what's the complicated way? :)
>
> If you define "idle" as having no mouse or keyboard activity then it's
> pretty easy.  Each time through your event loop just record the mouse
> position.  If it's the same as last time, the mouse hasn't moved.  Easiest
> way I've found for checking keyboard activity is to use GetKeys() and then
> just memcmp() each new result to the last time.
>
> If you want to go further and check for disk/network activity, etc., then
> I have no clue.

Use a jGNE filter INIT. Check for mouse location (as suggested above) and
for keydown events. If you want modifier keys, then you need to use
GetKeys.

I check for mouse location on idle events.

Just keep a "lastActivity" variable around and update it each time through.

For more help with jGNE filters, check for the various snippets and the
project called "jGNE Helper" in the archives about the Internet.

-Randall
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 13 Feb 1996 15:50:50 -0800
Organization: Apple Computer, Inc.

In article <4fc9h7$[e-mail]>,
[e-mail] (Jason Hoos) wrote:

 > Is there some simple way to tell from within C how long a Mac has
 > been idle for?

No. That was easy. :-)

 > If not, what's the complicated way? :)

I recommend something based on jGNEFilter. See my personal web pages for a
sample. The tricky part is defining "idle". If the Mac is sorting a large
database over a network (a lengthy, slow operation) and the user goes away
to get coffee, how do you know? Patch File Manager? Ugh. There are
probably 100 other cases to handle, too.

You haven't mentioned why you need to know this, but one way to leverage
somebody else's work is to write an AfterDark module.

- ---------

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From [e-mail] (Mark Aran Aiken)
Subject: KanjiTalk ignores GNEFilters?
Date: 1 Feb 1996 08:09:25 GMT
Organization: McGill University, Undergraduate EE Lab

Hello all,

    I'm collaborating with this guy to localize a shareware app of
mine to Japanese, and I noticed something very disconcerting.

    When running under KanjiTalk 7.5.2, if one is using a Japanese
script, a jGNEFilter I install never gets to see keystrokes. If an app
calls WNE, they get handed a keyDown event, but the System seems to
manufacture it from the intermediate input window without posting it
to the event queue.

    Can someone else confirm this? IM:Text (Which talks about the Text
Services) doesn't mention this, but then again, I haven't been able to
find jGNEFilters mentioned officially in any of the IM volumes.

    Am I stuck patching WNE and peeking at the results the app is
about to get for KanjiTalk?

    Mark

--

 -----------------------------------------------------------------------------
| Mark A. Aiken                          Macintosh wizard and shareware author|
| Undergrad, EE, McGill U, Mtl, CANADA   [e-mail] / [e-mail]  |
| WWW site of Macintosh shareware at     http://www.kagi.com/authors/marka    |
| General WWW home page at               http://www.ee.mcgill.ca/~marka       |
 -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Sat, 03 Feb 1996 12:39:05 -0800
Organization: Cellular

In article <4epsfl$[e-mail]>,
[e-mail] (Mark Aran Aiken) wrote:

 > I haven't been able to
 > find jGNEFilters mentioned officially in any of the IM volumes.

It's documented in IM I very very briefly and also:

    <URL:http://dev.info.apple.com/technotes/
        Archive/Toolbox/tb_11.html>

 > Am I stuck patching WNE and peeking at the results the app is
 > about to get for KanjiTalk?

I'm not familiar with any KanjiTalk problem. Copying this to myself for
bug report searching when I get back to work.

- -----------------------------

  Pete Gontier -- Apple Macintosh Developer Technical Support
  <URL:mailto:[e-mail]> -- <URL:http://www.dnai.com/~gurgle>

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 5 Feb 1996 05:42:11 GMT
Organization: University of Michigan

Mark Aran Aiken, [e-mail] writes:
 > When running under KanjiTalk 7.5.2, if one is using a Japanese
 > script, a jGNEFilter I install never gets to see keystrokes.

WorldScript bypasses the jGNE mechanism when reporting "keystrokes", since
keyboard input is often emulated by Inline Input windows. This means that
systems since 7.1 are susceptible... and patching _GetNextEvent may be your
only option. (WNE calls GNE, but recall that GNE is reentrant across
contexts.)


Pete Gontier, [e-mail] writes:
 > I'm not familiar with any KanjiTalk problem. Copying this to myself for
 > bug report searching when I get back to work.

I don't know if/where this is documented, but it certainly has been around
for a while. With the "tenative" future of the jGNE mechanism, I don't think
there are plans to fix the problems with it.

Besides, the "missing clicks" bug has been around since 7.0, and no one is
rushing to fix (or document) that.

Matt
(not as bitter as he sounds...)

* * * * * * * * * * * * * * * * * * * * * * * * * * ======================
*  Reality: Matt Slot                             *  Time is an illusion.
*  E-Mail:  mailto:[e-mail]             *  Lunchtime doubly so.
*  Web:     http://www.sils.umich.edu/~fprefect/  *     -- Douglas Adams
* * * * * * * * * * * * * * * * * * * * * * * * * * ======================

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 13 Feb 1996 18:00:57 -0800
Organization: Apple Computer, Inc.

In article <4f45bj$[e-mail]>,
Matt Slot <[e-mail]> wrote:

 > Pete Gontier, [e-mail] writes:
 >  > I'm not familiar with any KanjiTalk problem. Copying this to myself for
 >  > bug report searching when I get back to work.
 >
 > I don't know if/where this is documented, but it certainly has been around
 > for a while. With the "tenative" future of the jGNE mechanism, I don't think
 > there are plans to fix the problems with it.

Yep. I found a bug in the database, and it's still open.

  ---

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From "Patrick C. Beard" <[e-mail]>
Subject: [ANN] GC 4.9 for MacOS
Date: 14 Feb 1996 19:27:07 GMT
Organization: BasilSoft

The MacOS port of Version 4.9 of the Boehm-Demers-Weiser conservative
garbage collector for C and C++, is now available. This collector is
compatible with Symantec's THINK C/C++ (68K only), as well as
Metrowerks CW8 (68K & PowerPC).

This version no longer requires the use of datastart.c and dataend.c.
The collector now uses linker generated variables to locate global
data. There is also limited support for using the collector with shared
libraries.

Version 4.9 also contains miscellaneous bug fixes in the OS independent
portions of the collector.

The new version is available at:

ftp://ftp.bdt.com/home/beard/gc/gc-4.9.sit.hqx




---------------------------

>From [e-mail] (Sean McDowell)
Subject: [ANN] Visit Mac Games Programmers' Bitstop!
Date: Tue, 13 Feb 1996 03:58:51 GMT
Organization: University of Waterloo

I'd like to welcome you all over to my little corner of the Web, the Mac
Games Programmers' Bitstop. It's an organized, annotated list of internet
resources for us Mac games programmers.

I've added a few nifty sites, more will come when midterms are over :-(.
Drop me a note if you have any comments (it's lonely out here!) and enjoy
your visit: http://www.undergrad.math.uwaterloo.ca/~smmcdowe/Bitstop.html.

Sean
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sean McDowell                  "We should not let ourselves be burnt for
University of Waterloo          our opinions: we are not that sure of them.
http://www.undergrad.math.      But perhaps for this: that we may have and
uwaterloo.ca/~smmcdowe          change our opinions." -- Nietzsche

---------------------------

End of C.S.M.P. Digest
**********************